Enterprise based issuance of identification cards

ABSTRACT

Methods and associated systems for enterprise-wide issuance of identification cards. A single enterprise server component and a plurality of card issuance machine controller components are distributed over an enterprise network. Each card machine controller component controls one or more devices for the production of identification cards including, for example, embossed and/or digitally encoded information. The single enterprise server component acts as a server to route the card issuance requests to the proper card machine controller component on behalf of client programs at each location used to request the production of an identification card. The enterprise server component further provides enhanced security and encryption to provide requisite security in the exchange of sensitive information in the production of such identification cards. An administrative component, which can be used anywhere on the network, provides centralized management of common data used by the server, card machine controllers and client programs in the production of identification cards. The administrative component also provides for centralized administration of the plurality of PCs, card issuance machines and software components to permit easy re-assignment of future production requests for purposes of management and/or for end user convenience.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to production and issuance of embossed and/orencoded identification cards and more specifically relates to anenterprise-wide system for providing centralized control and managementfor issuance of such identification cards.

2. Discussion of Related Art

Issuance of identification cards is a critical task in many commercialand other endeavors. Exemplary of such endeavors are credit cardissuance, debit card issuance, frequent customer identification cardissuance, security card issuance, etc. Such identification cards ofteninclude embossed identification information and or digitally encodedidentification information. Such digitally encoded identificationinformation may be recorded on the identification card in a magneticstripe or other storage medium as well as in so-called “smartcard” chipsembedded within the identification card.

Generation of such identification cards has long been the exclusivedomain of complex, costly, large devices capable of both embossing thecards as well as programming digital identification information. In morerecent years, devices for issuance of such identification cards havedramatically fallen in price as well as shrunken in physical size(“footprint”). For example, the model 150 i embossing and encodingmachine produced by DataCard Corp. of Minneapolis is a relativelylow-cost device having a relatively small footprint (i.e., tabletop ordesktop configuration). The DataCard 150 i embossing and encodingmachine is capable of producing such cards under control of anexternally attached computing system such as a personal computer (“PC”).

Although older, larger devices were capable of producing much highervolumes of identification cards, the low-cost and small footprint of theDataCard 150 i makes it possible to distribute such functions into moreconvenient localized facilities. Localized issuance of suchidentification cards is often referred to in the industry as “instantissuance.” The paradigm of instant issuance allows for an identificationcard to be made while the user or customer waits rather than waitingdays or weeks for a centralized facility to produce such card and shipthe produced card to the end user.

Although devices such as the DataCard 150 i enable the decentralizedissuance of identification cards, computing systems to permit suchdecentralized issuance of cards while maintaining centralized control ofthe information embossed and/or encoded on such cards were notavailable.

The computing system called CardWizard® was produced and marketed byDynamic Solutions International of Colorado in 1997. This computingsystem is comprised of a collection of interrelated software componentsdesigned to work in a distributed client/server model within a singlelocation. Although designed in accordance with a single locationclient/server software model, when applied to a broader multi-locationenterprise environment, a number of problems arise in this and othercurrent solutions.

-   1. Financial identification cards require usage of highly sensitive    data used for encryption calculations that produce values that are    embossed and encoded on identification cards. This data is referred    to as “encryption keys.” To simplify software installation and    provide greater security, large banking and other large financial    enterprises prefer these encryption keys be stored at a single    secured location within the network rather than at each location    that has a card issuance machine. The original version of    CardWizard®, like other present solutions, required these encryption    keys to be stored at each location that had a card issuance machine.-   2. Administration and management problems arise where an enterprise    may have different capabilities at each of several decentralized    locations. For example, a large financial institution may issue ATM    cards in one location and debit cards in a different location. It is    therefore important for enterprise solutions to be easily    configured, administered and managed to permit production of    identification cards to be performed at a most appropriate location.-   3. Problems arise when decentralized locations, which cannot afford    the cost of an issuance machine, wish to issue cards on an issuance    machine located at another location within the network.-   4. Problems arise when locations want card production requests    stored in a queue that allows cards to be produced at a later time    at either their location or another location within the enterprise.-   5. Only a single card issuance machine is supported on a single PC.-   6. Support of external software processes in lieu of card issuance    machines was not available. For example, rather than producing the    card immediately at a card machine, it may be desired to route the    card information to another computer system on the network for some    other type of processing.-   7. Administration of card issuance machines, users, system access    and production reporting and management of system options had to be    done at each location rather than centrally.-   8. There are duplicate databases throughout the network, which    increases exposure to fraudulent activities and required more    systems administration activities to synchronize or replicate    updated information.-   9. Having “self contained” card issuance systems at a single    location presents the risk of someone stealing the equipment and    potentially using it to make illegal financial cards.

It is evident from the above discussion that a need exists for improvedenterprise coordination in the production and issuance of embossedand/or encoded identification cards in a decentralized manner.

SUMMARY OF THE INVENTION

The present invention solves the above and other problems, therebyadvancing the state of the useful arts, by providing improvedadministration and management of decentralized identification cardissuance in an enterprise-wide environment. In particular, the presentinvention includes features for using and managing multipleidentification card production machines distributed throughout theenterprise and for routing of production requests for identificationcards anywhere in the enterprise network.

More specifically, a card machine controller component (“CMC”) resideswithin a PC on the enterprise network and acts as a server at itsphysical location for connecting various configurations of card issuancemachines and/or external software processes. Card issuance machinesinclude devices such as the DataCard 150 i while external softwareprocesses include tasks such as writing card information to a disk fileor sending card information to another software application within theenterprise network. Multiple such card machine controller servercomponents may reside in PCs dispersed throughout the enterprisenetwork. The card issuance machine controller component communicateswith client processes within the enterprise for purposes of producingidentification cards at that location.

As used herein, card issuance components includes card issuance machinessuch as DataCard products as well as other devices for creatingidentification cards and further includes external software processesfor application specific custom software modules to createidentification cards outside the scope of a particular machine. Further,as used herein, card issuance controller and CMC refer to a controlmodule of the present invention that controls low level operations ofone or more card issuance components.

An administration component of the present invention interfaces with thesingle enterprise server component to coordinate access to centralizedinformation required in production of cards and to permit enhancedmanagement of the distribution of card production requests toappropriate card issuance machines in the enterprise.

An aspect of the present invention enables a user-friendly graphicaluser interface to manage the definition of the entire enterprise's cardproduction network. This definition includes configuration of eachdecentralized location including, but not limited to, the users, PCs,card issuance machines, which types of cards are allowed to be producedby a location and/or user and where each type of card will be produced.The graphical user interface (“GUI”) allows an administrator to changethe configuration as needed. For example, if it is desired to havefuture production of a type of card at a different card issuancemachine, the administrator can use a simple drag and drop operation toeffectuate this change.

Another aspect of the present invention enables a user-friendlygraphical user interface to manage the assignment and re-assignment ofpending card production requests to appropriate card issuance machinesdistributed in the enterprise. The GUI allows an administrator to dragand drop card issuance requests presently assigned to a first cardissuance machine to a different machine. This feature simplifies themanagement of the enterprise-wide production of identification cards bypermitting the administrator to re-assign a production request toanother issuance machine. For example, if a first issuance machinebecomes inaccessible due to failure or is otherwise overloaded withrequests, another machine at the same location or at another convenientlocation may be assigned the task of producing a queue of such requestedcards.

A still further aspect of the present invention lies in centralizedsecurity for the decentralized card issuance machines of the enterprise.A central administration component provides a central point of controlfor security including user ID's and related password protection for useof the card issuance machines and encryption of sensitive informationexchanged between the enterprise server component and the distributedcard machine controller components.

The above, and other features, aspects and advantages of the presentinvention will become apparent from the following descriptions andattached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a network diagram showing a sample enterprise configuration ofthe present invention. The diagram shows physical devices such as PCsand card issuance machines in addition to the various softwarecomponents installed within each PC.

FIG. 2 is block diagram showing the various software components in anenterprise card issuance environment using the present invention. Thediagram shows communication paths between the various components.

FIG. 3 is a software flowchart of the operation for the enterpriseserver component for the present invention.

FIG. 4 is a software flowchart showing the enterprise server component'sinitialization logic.

FIGS. 5 through 10 are exemplary graphical user interface displayscreens used in conjunction with the methods and structures of thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

While the invention is susceptible to various modifications andalternative forms, a specific embodiment thereof has been shown by wayof example in the drawings and will herein be described in detail. Itshould be understood, however, that it is not intended to limit theinvention to the particular form disclosed, but on the contrary, theinvention is to cover all modifications, equivalents, and alternativesfalling within the spirit and scope of the invention as defined by theappended claims.

FIG. 1 is a block diagram of a system 100 in accordance with the presentinvention. System 100 depicts a number of exemplary elements of theenterprise card issuance system of the present invention. Those skilledin the art will recognize a wide variety of equivalent configurationsand topologies in which the present invention may be advantageouslyapplied. Specifically, the present invention accommodates a scaleableenterprise network utilizing client/server programming techniques wellknown to those skilled in the art. In such client/server programmingparadigms, client processes and associated server processes may beco-resident within particular computing devices or may be widelydistributed among a variety of computing devices of the enterprisecommunicating via a network communications medium and protocol. As shownin FIG. 1, all elements preferably communicate via TCP/IP communicationsnetwork 150.

Within the present invention PCs are defined as members of “PC Groups”.Normally a PC group consists of PCs residing at the same physicallocation. However, a PC group may consist of PCs located at differentphysical locations. In FIG. 1, there are three PC groupsdefined—“Central Operations” 162, “Location A” 160 and “Location B” 164.

Enterprise server software component 130 residing in PC 110 at CentralOperations location 162 provides centralized management and control foradministration of system 100 in accordance with the present invention.The management and administration services provided by enterprise server130 are accessed by administrative client 132 operable in PC 106, PC 110and PC 112 in the various locations 160, 162 and 164, respectively. Morespecifically, administrator software component 132 provides a graphicaluser interface client process for an administrative user to centrallycontrol, configure, and manage system 100.

PCs 102 through 108 and PCs 112 through 116 generally provide a clientprocess interface 134 for on-site requests for issuance ofidentification cards. PCs 106, 108 and 116 further provide a directinterface to card issuance machines 120 through 126. The interface tosuch card issuance machines 120 through 126 is provided by card machinecontroller component 136 operable within PCs 106, 108 and 116.

As noted above, those skilled in the art will recognize that thespecific topology and configuration of system 100 in FIG. 1 is intendedmerely as exemplary of any number of similar enterprise configurations.In particular, any number of PCs may be assigned to a particular PCgroup and any number of PC groups may be defined in the enterprise. Thepreferred physical locations of PCs is simply that which is convenientand beneficial for the enterprise and its customers. Similarly, thephysical locations of card issuance machines 120 through 126 is thatwhich is convenient for issuance of cards by the enterprise organizationand further convenient for the enterprise customers.

FIG. 1 also indicates that each of card machines 120 through 126 may bedesignated for production of a particular type of identification card.For example, in a financial or banking enterprise application,particular card issuance machines may be designated for issuance of ATMcards while other card issuance machines may be designated for issuanceof ATM or debit cards. Card issuance machine 120 is designated in theexemplary enterprise of FIG. 1 as primarily a debit card issuancemachine while card issuance machines 122, 124 and 126 are designated asprimarily ATM card issuance machines. As above, the particulardesignation of each machine and its physical locations in the enterpriseis that which is convenient and useful for the enterprise and itscustomers. Administrative, management and configuration functionsprovided by enterprise server software component 130 on PC 110 permitsuch flexibility in the location and designation of devices distributedin the enterprise.

Where FIG. 1 shows the overall architecture of an exemplary topology ofan enterprise, FIG. 2 is a block diagram showing the functionalrelationship among all elements and processes operable within anenterprise exemplified in FIG. 1. An optional custom interface softwarecomponent 152 is generally operable in conjunction with host system 202and is preferably physically co-resident with enterprise server softwarecomponent 130 in a physical location 200 designated as the centraloperations location. Remote locations are shown an exemplary singleremote location 220 on FIG. 2.

Optional security processor hardware element 208 operates in conjunctionwith enterprise server software component 130 to provide requisitestorage of a financial institution's encryption keys and theencryption/decryption processes required by the enterprise server 130.Encryption keys and related encryption rules can be maintained by anadministrative user using the key manager element 138. These encryptionkeys and encryption rules are stored in either the optional securityprocessor 208 or the card format database 214.

The network configuration database 210 contains information used by theenterprise server software component 130 for management of the networkand routing of card production requests to the proper card issuancedevice 236 at a remote location 220 in the network.

The card format database 214 contains definitions of various types ofidentification cards (also referred to herein as “card type” or “cardtype information” or “card format”) available for production within theenterprise. Each production request includes a corresponding card typeindicating the type of card for which the information is to be produced.Each definition provides the rules and specifications for embossing andencoding the card. These rules are created and maintained by thedesigner component 154 and utilized by the enterprise server component130 during the fulfillment of production requests submitted by clientcomponents 134, 140, 142 and 150. In particular, standard clientcomponent 134 submits requests to produce a particular format of card.Such requests are produced by a user filling in a form on a PC in aremote location. Batch input client 140 generates a batch of cardrequests from a prepared file or database. Repin component 142 generatesrequests to change a personal identification number (“PIN”) on apreviously issued identification card. Such requests are typicallyprocessed at a special terminal device designed for the purpose ofchanging the PIN encoding on the card.

The CMC device “request queues” database 216 contains a collection ofqueues for each defined device assigned to the card machine controllersin the enterprise. These queues provide temporary storage of cardproduction requests received from client components 134, 140, 142 and150 that are directed to a specific card issuance machine 236 orexternal software process 238.

Optional production queue database 212 contains information used by theenterprise server software component 130 for temporary storage of cardproduction requests received from client components 134, 140, 142 and150 that are directed to a specific production queue. Requests held inthis production queue database 212 are not produced until requested by auser using the Administrator software component 224 at a remote location220. At that time, the card will be produced at a card issuance device236 attached to a CMC software component 136 located at a remotelocation 220 specified in the network configuration database 210.

These centralized host based elements communicate via standard TCP/IPcommunications media and protocols with elements physically resident ateach location. 220. A typical location 220 optionally may include anumber of custom client user interface elements 150 and/or standardclient user interface elements 134, 140 and 142. Client user interfaceelements 150, 134, 140 and 142 provide the graphical user interface forcustomers and or enterprise customer service representatives to generateand enter requests for production or repinning of identification cards.Such requests by client user interface elements 150, 134, 140 and 142are directed via the network to enterprise server 130 typically residentin the central operations location 200.

In addition to client user interface elements 150, 134, 140 and 142,elements 224, 226 and 154 represent other standard interface elementsprovided at a remote location 220. Such standard elements may includecomponents for administrative functions such as user maintenance,reporting and card stock inventory management (element 224);administration of a financial encryption keys (element 226); and designof specific card formats to be produced by the system (element 154).

For example, a particular location may design a new style or format ofidentification card, may issue requests for batches of identificationcards to be produced, and may administer particular aspects ofidentification information and security information useful to servicerepresentatives at the particular remote location 220 as well as usefulto particular customers at that location. Such local management requestsare also directed to enterprise server 130 through standard networkcommunications.

Though not required, a particular remote location 220 may provide anumber of local card issuance machines 226 or external softwareprocesses 238. Such card issuance machines and external softwareprocesses are interfaced by a card machine controller (CMC) softwarecomponent 136. Each CMC software component interfaces one or moreappropriate card issuance devices or external software processes.

A client user interface element 134, 140, 142 or 150 generates a requestat a remote location 220 for issuance of a particular type ofidentification card. The request is forwarded to the enterprise server130 located at a physical central operations location 200. The requestis communicated via standard network communication media and protocols,preferably TCP/IP network protocols and associated network communicationmedia. Information required for production of the requestedidentification card may be obtained locally by the client user interfaceelement 134, 140, 142 or 150 as well as centrally provided by operationof the enterprise server 130. For example, details of the particularcustomer or account information for the particular customer ispreferably centrally stored at the central operations location andaccessed in a controlled manner through the optional Custom Interfacesoftware component 152. Any sensitive or confidential informationtransferred between the enterprise server 130 and client user interfaceelements 134, 140, 142 and 150 and card machine controller element 136is preferably encrypted to maintain security through the network. If thecard is to be issued, the information necessary to emboss and/or encodethe card is generated using the card format database 214.

Card format database 214 contains definitions for each type of cardknown to the enterprise for production. This definition includesplacement of information on a card, style of production of theinformation (i.e., encoded and/or embossing), application specificinformation (i.e., financial calculations relating to banking etc.),type of card stock/media (i.e., plastic embossed cards, magneticstripes, “smart” cards, etc.) and other information required to generateany particular type of card used in the enterprise.

Using the network configuration database 210 the enterprise serverdetermines which card machine controller component and which cardissuance device or external software process to use for the request. Theinformation is then encrypted and transferred from the enterprise server130 to the appropriate CMC software component 136 in the enterprise. Thecard machine controller component 136 then communicates with theappropriate card issuance device 236 or external software process 238 toproduce the card. Optionally, the information communicated to the cardissuance device or external software process may also be encrypted foradditional security.

The server interface element 144 allows custom client user interfaces150 to easily communicate with the enterprise server component 130 byproviding a standard programming interface. The PIN pad interface OCXelement 146 provides a standard programming interface between clientcomponents 134 and 150 and PIN entry machines 147. These PIN entrymachines allow a customer to select their current PIN and optionallyselect a new PIN. The host interface OCX component 148 provides astandard programming interface between the custom client user interface150 and the host system 202. This interface allows simplifiedtransmission of information between the two elements.

As noted above, those skilled in the art will recognize that thefunctional decomposition of elements and the physical locations of suchelements as shown in FIG. 2 is intended merely as exemplary of onepreferred embodiment. The client/server programming paradigm permits thevarious client processes and server processes to be distributed anywherein the enterprise network. Further, the specific breakdown of componentsmay differ depending on specific design choices in implementing thefeatures of the present invention.

FIG. 3 is a flowchart describing the operation of the enterprise serverelement depicted above FIGS. 1 and 2. In general, the enterprise serverprocess initializes when it commences operation and then awaits receiptof an event message indicative of an operation requested by a clientprocess within the enterprise or from the enterprise server's internalclock timer. Requests are directed to the enterprise server from clientuser interface processes for production of cards and card machinecontroller elements as well as from the client administrative userinterface for reconfiguration or other management operations of thepresent invention.

Element 300 represents processing to initialize operation of theenterprise server. Among other functions, the initialization processingincludes discovery and initialization of card machine controllercomponents in the network. Asynchronously, each card machine controllerinitializes each of the issuance machines or external software processesit is designated to control. Further details of such initializationprocessing are provided herein below with respect to FIG. 4.

In the preferred embodiment, the server process awaits receipt of eventmessages from card machine controller processes with card productioncompletion notifications and client processes requesting services fromthe enterprise server process. In addition, every two seconds, or othertime interval so established, a timer event occurs and the serverprocess checks each issuance machine queue to see if a card requestneeds to be processed. Element 302 therefore represents processing bythe enterprise server process to await receipt of a supported timerevent or a client initiated event message. Upon receipt of such anevent, the method then continues by processing the received event inaccordance with a type indicated therein. Exemplary of such client eventmessages in the preferred embodiment are: a client request to produce anidentification card, an indication that production of a requestedidentification card has completed, an administrative user client requestto associate a newly designed card format with a particular issuancemachine or its associated queue, and a request to administer, configureor manage the card issuance enterprise system of the present invention.

Those skilled in the art will recognize that the particular events to beprocessed by the enterprise server are a matter of design choice in theimplementation of the present invention. The particular events depictedin FIG. 3 are therefore intended merely as exemplary of typical eventsthat may be processed by enterprise server operable in accordance withthe present invention. Furthermore, those skilled in the art willrecognize a variety of other programming paradigms useful inimplementing features of the enterprise server. An event driven model asdescribed herein with respect to FIG. 3 is therefore intended asrepresentative of all such solutions.

In response to a request to produce an identification card, elements 304through 314 are operable to process the request. Element 304 firstchecks the request to make sure all required information is provided(i.e., the request is valid). If the request is not valid element 306 isoperable to notify the originating client of the problem and processingloops back to element 302 to await a next event. If the request isvalid, element 308 next performs any requisite processing to calculateor reformat information for the card to be produced. For example, infinancial applications of the present invention, ATM or credit cardshave calculations involving customer PIN selection or assignment.Element 310 is next operable to determine whether the request is to beplaced on a production queue for later processing or is to be routed toa queue associated with a card machine or external software process forprocessing. If routed to a production queue, element 312 is operable toqueue the request on an identified production queue for laterprocessing. If the request is to be processed now, element 314 routesthe request to the queue of the identified card machine or externalsoftware process. In both cases, processing loops back to element 302 toawait a next event.

Every two seconds, element 320 checks to see if more issuance machinequeues need be checked. If all issuance machine queues have been checkedprocessing completes for this timed event and continues at element 302(label A) to await occurrence of another event. If more queues remain tobe checked, element 322 gets information for the next card issuancemachine queue. Element 324 then determines whether the card issuancemachine or external software process associated with the queue orotherwise identified by the request is presently busy servicing otherrequests. If the machine or process is busy, processing continues bylooping back to element 320 to check additional issuance machine queues.If the machine or process is not busy, processing continues with element326 to unqueue the next request queued for the identified card issuancemachine and transmit the unqueued request to an appropriate card machinecontroller responsible for controlling operation of the identified cardissuance machine. Processing then continues by looping back to element320 to determine if more queues remain to be processed.

Processing by the card issuance machine proceeds asynchronously withrespect to the enterprise server. Completion of the card productionrequest will be signaled to the enterprise server by a subsequent eventmessage as discussed below.

In response to receipt of an event message signifying completion of anidentification card production request, element 330 is operable todetermine if the card was completed or an error occurred. If completedwithout errors, the client process that submitted the original requestis notified of the completion with element 336 and then element 338 isoperable to determine whether additional requests remain queued for thecard issuance machine identified in the completion event message. If so,processing continues at element 340 to unqueue a next production requestand transmit the request to the identified card machine controller andthen loop back to element 302 (label A) to await receipt of the nextevent. If no further requests are presently queued for the identifiedcard machine, processing continues by looping back to element 302 (labelA).

If element 330 determines that an error occurred in processing arequest, element 332 is operable to notify the originating clientprocess of the error. Element 334 then suspends processing of furtherrequests for this queue until the problem is corrected by an operator.Processing then continue by looping back to element 302 (label A) toawait receipt of another event.

In response to receipt of an administrative reconfiguration ormanagement event message, element 360 is operable to reconfigure theenterprise card issuance system in accordance with parameters suppliedin event message. As noted elsewhere herein, an administrative user ofthe enterprise server may reconfigure the system to associate particularPCs with particular PC Groups, to associate particular card issuancemachines with particular PC Groups and PCs, to associate particular cardformats with particular card issuance machines, etc. Processing thencontinues by looping back to element to 302 (label A) to await receiptof another event message.

In response to receipt of an event message requesting a change in therouting of future card requests from one card issuance machine toanother, element 370 is operable to so make this change. Element 372then notifies the appropriate affected clients of the routing change.Processing then continues at element 302 (label A) as described above.Such a request may be initiated by an administrative client process inresponse to graphical input to “drag and drop” of selected routingdefinitions.

FIG. 4 is a flowchart describing additional details of the processing ofelement 300 to initialize the enterprise card issuance system of thepresent invention. Element 400 is first operable to open all systemdatabases. Element 401 then identifies all card issuance machinecontroller elements present in the enterprise as defined in the systemdatabase (210 of FIG. 2). As noted above, a card issuance machinecontroller element is operable within a PC in locations that physicallyinclude card issuance machines. The card issuance machine controllerelement is a module operable in a PC at such a location to manage theproduction operations of one or more card issuance machines. Theidentity and location of all such card issuance machine controllers isused by the enterprise server to prepare its initial configurationinformation.

Element 402 then creates a queue associated with each card issuancemachine present in the enterprise system. Element 404 then determineswhether all CMC components in the enterprise have been processed byelements 406 through 412. If no further CMC components remain to beprocessed, processing of element 300 is complete. If more CMC componentsare to be processed, element 406 is operable with respect to the nextCMC component to attempt to establish a connection therewith. Element408 then determines whether the attempted connection was successful. Ifnot, processing of this CMC component is complete and processing loopsback to element 404 to process additional CMCs. If the connectionattempt succeeds, element 412 transmits configuration information fromthe network configuration database (210 on FIG. 2) to the CMC component(136 on FIG. 1). This configuration information informs the CMCcomponent of the types of card issuance machines attached to, orexternal software processes associated with the CMC component and theinterfaces to be used (i.e., the physical and logical configuration ofthe CMC component and its card issuance machines and external softwareprocesses, elements 236 and 238 respectively.) Processing then loopsback to element 404 to process remaining CMC components.

Those skilled in the art will recognize that the flowcharts of FIGS. 3and 4 are intended merely as representative of one exemplary embodimentof the enterprise server system of the present invention. A number ofequivalent alternate embodiments will be readily apparent to thoseskilled in the art. Such design choices in implementation are well knownto those of ordinary skill in the art.

FIGS. 5 through 10 are exemplary screen images depicting typical userinterface techniques for implementation of the enterprise card issuancesystem of the present invention. In particular, these screen images arerepresentative of screens typically used by an administrative user toconfigure and manage the enterprise card issuance system of the presentinvention.

FIG. 5 depicts elements and resources available in a typical enterprisesystem in accordance with the present invention. In FIG. 5, the firsttwo elements 502 and 504 identify production queues in which requestsfor associated types of cards are queued awaiting production by anassigned card issuance machine. In particular, the first queue 502 named“ATM Cards” is assigned to a card issuance machine named “MainOffice\PC100\DataCard 28x/295.” A second queue 504 named “Visa DebitCards” is assigned to the same card issuance machine named“MainOffice\PC100\DataCard 28x/295.” A PC group 506 named “Branch 1” hastwo PCs 508 and 510 associated therewith and named “PC200” and “PC202.”The PC group 506 does not have a card issuance machine. Two card formats512 and 514 named “ATM Card” and “Visa Debit Card”, are associated(“linked”) with requests generated by clients operating on all PCs of“Branch 1.” All requests submitted for production of “ATM Card” cardformats will be stored in the system production queue 502 named “ATMCards.” Similarly, all requests submitted for production of “Visa DebitCards” will be stored in the system production queue 504 named “VisaDebit Cards.” At some future time, an administrative user can instructthe system to produce the cards being stored in these production queues.In this example, both types of cards will be produced at the DataCard28x/295 card issuance machine located in the Main Office as discussedbelow (i.e., the card issuance machine to which the production queue iscurrently linked).

FIG. 5 also identifies resources in a Main Office 516 including two PCs:element 520, named “PC100” and element 518 named “COMPAQ—NT.” Operablewithin PC 520 (“PC100”) is a card machine controller 522 for controllingtwo card issuance machines, a DataCard 150 i card issuance machineelement 524 and a DataCard 28x/295 card issuance machine, element 526.Two card formats 528 and 530, named “ATM Card” and “Visa Debit Card”,respectively, are associated with PC Group 516 named “Main Office” forproduction on the attached DataCard 150 i card issuance machine 524.

The various elements of the enterprise are shown in a “tree” structureto reflect the physical and logical relationships among the elements.The physical relationships are the physical proximity of the elements.In other words, PCs that are members of the PC group “Main Office” areshown under the branches of the tree display rooted at element 516 “MainOffice”. In addition to PCs defined within each PC group are routingdirectives (“links”) for the various card formats at either the PC groupor PC level. These links specify either a particular card issuancemachine or a specific production queue.

Production queues, elements 502 and 504, are available for the entireenterprise and are linked, similar to how card formats are linked, tospecific card issuance machines. However, card requests in theproduction queues are not produced until so directed by anadministrative user at a later time. At that time, all card requests inthe specified production queue will be produced at the currently linkedcard issuance machine.

Card format and production queue links are logical relationships thatthe administrative user can create and modify using simple drag and dropmanipulations on the displayed graphical tree structure. For example, inorder to create a new card format link and associate it with a cardissuance machine queue an administrative user would perform thefollowing exemplary steps on the graphical user interface shown in thefollowing figures.

-   1. As shown in FIG. 6, right click on element 602 which defines a PC    group named “Main Office”.-   2. A popup menu appears as shown in FIG. 7.-   3. Click on the popup menu choice “New Card Format Link . . . ”    element 702 on FIG. 7.-   4. A window appears as shown in FIG. 8.-   5. Select the card format to create a link. In this example we    select “Visa Credit Card”, element 802 and then click on the OK    button element 804.-   6. The card format link appears in FIG. 9 as element 904 with a link    definition 906 as “Needs to be linked”.-   7. The user clicks on the icon for the link, element 904, and drags    the icon to the icon element 902 that represents the card issuance    queue for a particular card issuance machine.-   8. When the icon being dragged is released, the card format is    linked to this queue as indicated by the link definition 1006 “Main    Office\PC100\DataCard 28x/295)” in FIG. 10.

While the invention has been illustrated and described in detail in thedrawings and foregoing description, such illustration and description isto be considered as exemplary and not restrictive in character, it beingunderstood that only the preferred embodiment and minor variants thereofhave been shown and described and that all changes and modificationsthat come within the spirit of the invention are desired to beprotected.

1. A system for issuance of identification cards in an enterprise, saidsystem comprising: a plurality of card issuance components forproduction of identification cards of different types; a card issuancecontroller coupled to said plurality of card issuance components forcontrolling said plurality of card issuance components to servicerequests for said production of identification cards, wherein therequests include production of cards of different types including atleast two of a debit card, an ATM card, a credit card, a mag stripe cardand a smart card; an enterprise server coupled to said card issuancecontroller through an enterprise network for managing requests forproduction of said identification cards, wherein the enterprise serveris configured to determine an appropriate card issuance component toproduce the card based at least in part on the card type and to transmitproduction information to an appropriate card issuance controller toproduce the card; and a card issuance client coupled to said enterpriseserver through the enterprise network for generating requests for saidproduction of identification cards.
 2. The system of claim 1 whereinsaid enterprise server includes: a card issuance component queuecorresponding to each of said plurality of card issuance componentswherein each request of said requests is entered into one of the cardissuance component queues corresponding to a selected component of saidplurality of card issuance components and wherein the enterprise serveris configured to monitor the status of each of the card issuancecomponent queues and to transmit production information from the cardissuance component queues to the card issuance controller for subsequentproduction by the card issuance component.
 3. The system of claim 2wherein said enterprise server further includes: at least one productionqueue includes production requests for later production, and whereincard production requests that are in the production queues may be movedto one of the card issuance component queues when ready for production.4. The system of claim 1 further comprising: an administrative clientcoupled to said enterprise server through the enterprise network forproviding a user interface for managing a network configuration databasefor said production of identification cards.
 5. The system of claim 4wherein said administrative client includes: a graphical user interfaceelement to enable a user to administer aspects of said system whereinsaid graphical user interface includes iconic representationscorresponding to each of said plurality of card issuance components,wherein the graphical user interface is configured to permit futurerequests generated by the card issuance client to be directed todifferent card issuance components or to different production queuesusing a drag and drop feature.
 6. The system of claim 4 furthercomprising: a card issuance component queue for cards that are ready tobe produced, the card issuance component queue corresponding to each ofsaid plurality of card issuance components wherein production requestsare selectively entered into said card issuance component queuecorresponding to a selected component of said plurality of card issuancecomponents; at least one production queue for cards that are to beprocessed at a later time, the production queue corresponding to onecomponent of said plurality of card issuance components whereinproduction requests are selectively entered into said production queuecorresponding to a selected component of said plurality of card issuancecomponents, wherein said graphical user interface further includesiconic representations of each said card issuance component queue and ofeach said production queue.
 7. The system of claim 6 wherein saidgraphical user interface is operable to permit an administrative user toroute future card production requests to a desired alternate cardissuance component queue corresponding to another card issuancecomponent of said plurality of card issuance components or to analternate production queue corresponding to another card issuancecomponent of said plurality of card issuance components.
 8. The systemof claim 1 further comprising: a database for centrally storingidentification information and related information associated with saidrequest.
 9. The system of claim 1 further comprising: a card formatdatabase having information regarding types of cards to be producedwithin the system, wherein the card types include at least two of adebit card, an ATM card, a credit card, a mag stripe card and a smartcard.
 10. The system of claim 1 further comprising: a plurality ofqueues each of which corresponds to one of said plurality of cardissuance components wherein each request of said requests is enteredinto a selected queue of said plurality of queues corresponding to aselected component of said plurality of card issuance components; andlinks stored within a network configuration database associating each ofsaid requests with said queue based at least in part on the type of cardidentified in each said request. 11-16. (canceled)